================================================================================
ADAM TAPE 6801 -- FORMAT ROUTINE SIMULATION REPORT
On-drive DDP formatting: cycle-level 6801 execution + tape-stream verification
================================================================================
Date: 2026-06-14
Subject: Proving FORMAT6801.ASM, executed on a simulated 6801, emits a tape
         byte stream that the stock drive firmware will accept as a valid,
         formatted Digital Data Pack.

--------------------------------------------------------------------------------
1. METHOD
--------------------------------------------------------------------------------
A real instruction-level M6801 core executed the NEW FORMAT code opcode by
opcode (FORMAT loop, BUILD_HDR, ERASE_BUF, WR_ENABLE/DISABLE). The four stock
leaf routines were trapped at their true ROM addresses and modeled by their
documented byte-level effect:

    A_FF9D  SER       -> append the byte at [X] to the tape stream
    A_FD2B  MOTORDLY  -> (timing only; no bytes)
    A_FDCB  CHK_EOT   -> report "not end of tape"
    A_FC94  MOTOR_OFF -> (no bytes)
    A_FEF6  WR_SETUP  -> emit sync + 1024 payload + sync + 2 checksum bytes

This is faithful because every tape byte the routine commits passes through
SER or WR_SETUP; trapping them captures the exact on-tape byte stream in order.

--------------------------------------------------------------------------------
2. EXECUTION RESULTS
--------------------------------------------------------------------------------
HE (center) format:  1,276,384 instructions executed; 256,321 tape bytes
GW (right)  format:  1,276,256 instructions executed; 256,321 tape bytes

Track leader: 2753 zero bytes before first sync (matches Cherryhomes 2.2).
Block frames decoded: 128 per track (256 logical blocks across two tracks).

--------------------------------------------------------------------------------
3. HEADER VERIFICATION (firmware read-path rules, A_FE24..A_FE51)
--------------------------------------------------------------------------------
Every one of the 128 emitted block headers was decoded and checked against the
EXACT rules the stock firmware applies on read:

    Rule 1  Header ID in {GW=4757, HE=4845}                  PASS (128/128)
    Rule 2  ~block - notblock == 0  (coma/comb/subd)         PASS (128/128)
    Rule 3  sum(B5..BD) + 1 == 0 (mod 256)                   PASS (128/128)
    Rule 4  count word at BB:BC == 0x0080 (ldd A_00BB)       PASS (128/128)

Both HE and GW formats: ALL HEADERS PASS.

Representative HE headers (sync + 9 header bytes):
    block   0 : 16 48 45 00 00 FF FF 00 80 F4
    block   1 : 16 48 45 00 01 FF FE 00 80 F4
    block   2 : 16 48 45 00 02 FF FD 00 80 F4
    block 127 : 16 48 45 00 7F FF 80 00 80 (cksum per block)

--------------------------------------------------------------------------------
4. PHYSICAL PLACEMENT (MANGLE_NUM cross-check vs SD-DDP Build Guide)
--------------------------------------------------------------------------------
The HE center format places the directory via MANGLE_NUM:
    physical = (logical + 64) mod 128

    logical block 1 (directory) -> physical block 0x41 (65)

Eric Pearson's Coleco ADAM SD-DDP Build Guide states:
    "Directory starts at block 41h (65) ... Track 65 as block 1"

    MATCH: confirmed. The simulated output reproduces the real unit's
    documented directory placement exactly.

--------------------------------------------------------------------------------
5. ARTIFACTS PRODUCED
--------------------------------------------------------------------------------
    blank_formatted.ddp   262,144 bytes (256 x 1024) -- payload image for the
                          SD-DDP unit / MAME. All-zero payload = blank pack.
    he_tape_stream.bin    Full captured HE tape byte stream (headers + payload
                          + sync + gaps) for signal-level inspection.

--------------------------------------------------------------------------------
6. WHAT THIS PROVES AND WHAT REMAINS
--------------------------------------------------------------------------------
PROVEN (in simulation):
  - The FORMAT routine's logic is correct: it builds and emits, for all 128
    blocks per track, headers that satisfy every firmware read-verify rule.
  - Block numbering is contiguous 0..127 and the directory lands where the
    real SD-DDP unit expects it.
  - Both HE and GW formats are generated correctly from the same code path.

NOT YET PROVEN (requires hardware / MAME analog layer):
  - Real-world bit-cell timing: the simulation traps the serializer, so it
    verifies BYTES, not the 70us analog waveform. The serializer is reused
    verbatim, so timing is inherited from stock firmware, but a MAME or scope
    capture should confirm on real silicon.
  - Physical write-head behavior, motor ramp, and end-of-tape detection on a
    real transport.

RECOMMENDED NEXT STEP:
  Load the overlay into a MAME ADAM tape-6801 context, run FORMAT, capture the
  generated waveform via castool, and confirm a round-trip read of a known
  payload. Then test on real hardware in the SD-DDP unit.
================================================================================
